The present invention relates to computer graphics, and more particularly to vertex processing in a graphics pipeline.
Conventional vertex processing for three-dimensional (3-D) graphics programming application program interfaces (APIs) such as Open Graphics Library (OpenGL(copyright)) and D3D(trademark) provide support for per-vertex lighting, position transformation, and texture coordinate generation. The computations provided by such conventional vertex processing are routinely implemented by 3-D graphics hardware that greatly accelerates these operations.
One drawback of the aforementioned conventional vertex processing is that it is configurable, but not programmable. When using conventional vertex processing, an application can enable and disable various options, set transformation matrices, lighting, and texture coordinate generation parameters. However, such applications are limited to the set of computations provided by the conventional vertex processing feature set.
While the feature set has been gradually extended over time to support multiple texture units, and more texture coordinate generation modes and vertex blending schemes, the conventional vertex processing model is still fundamentally configurable, not programmable.
Conventional vertex processing assigns names to per-vertex quantities such as xe2x80x9cpositionxe2x80x9d, xe2x80x9ccolorxe2x80x9d, and xe2x80x9csurface normalxe2x80x9d. These names convey a sense of how the quantities are processed by conventional vertex processing. For example, surface normals are used for lighting vertices. The quantities"" meaning is directly tied to the operations performed with the quantity by conventional vertex processing. Similarly, other quantities such as xe2x80x9clight positionxe2x80x9d, xe2x80x9clight colorxe2x80x9d, and xe2x80x9cmodelview matrixxe2x80x9d are named to convey how these quantities are used by conventional vertex processing.
Existing applications use API commands named based on the conventions of conventional vertex processing. For example, a vertex may be set in the manner shown in Table 1.
Named 4xc3x974 matrix transforms are specified and manipulated in the manner shown in Table 1A, in accordance with conventional vertex processing conventions.
In contrast with conventional vertex processing, application-programmable vertex processing has no pre-existing meaning for the quantities used to process vertices. Instead, there is simply a predetermined amount of numbered per-vertex quantities (per-vertex variables) and a predetermined amount of state numbered quantities (per-vertex constants). How these quantities are used to process the vertices depends on the application-supplied vertex program""s instruction sequence.
For example, a vertex may be set in the manner set forth in Table 1B.
A 4xc3x974 matrix cannot be loaded as a single entity, but rather can be loaded as 4 rows of 4-element vectors. Note Table 1C.
The fact that vertex attribute xe2x80x9c2xe2x80x9d represents a normal and vertex parameter xe2x80x9c21xe2x80x9d represents row xe2x80x9c1xe2x80x9d of a matrix is determined by the instruction sequence of the application-supplied vertex program.
3-D applications use 4xc3x974 matrices to transform positions, normals, and other quantities. The matrices are typically manipulated in a hierarchical scheme using a matrix stack. The OpenGL(copyright) API provides commands for manipulating matrices and controlling various matrix stacks.
For example, to render a motorcycle, an application may manipulate the modelview matrix as set forth in Table 1D.
A software developer may want to adapt the rendering routine (renderMotorCycleWithoutWheels and renderWheel) to use application-programmable vertex processing. Conventional vertex processing always uses the current modelview matrix state to transform vertex positions. However, with application-programmable vertex processing, it is up to the vertex program to transform the vertices by the appropriate numbered vertex program parameters containing the modelview matrix values.
While application-programmable vertex processing provides tremendous flexibility in comparison to conventional vertex processing, 3D applications such as the example of Table 1D may, however, assign their own meaning to vertex processing quantities rather than have meanings assigned by the conventions of conventional vertex processing. This distinction between convention-specified and program-specified semantics for vertex processing quantities presents a significant hurdle to integrating application-programmable vertex processing into existing applications.
There is thus a need for a set of API features that facilitate combining application-programmable vertex processing with existing 3D applications originally authored to use conventional vertex processing.
There is a further need for API features that reduce the effort required to augment an existing 3D application to use application-programmable vertex processing.
A system, method and computer program product are provided for tracking a matrix during vertex processing. Initially, a request is received to track a matrix. Such matrix is identified in the request. The identified matrix is then tracked for vertex processing. In one aspect of the present embodiment, a version, type, and/or name of the matrix is identified in the request.
Also provided is a data structure stored in memory for tracking a matrix during vertex processing in the foregoing manner. Such data structure includes a command for requesting a matrix to be tracked. Further, the command includes an identifier for identifying the matrix. In use, the identified matrix is tracked for vertex processing upon execution of the command.
In various aspects of the present embodiment, the command may include a version identifier for identifying a version of the matrix. Such version may include an inverse version, a transpose version, and/or an inverse-transpose version. Still yet, the command may include a type identifier for identifying a type of the matrix. Such type may include a modelview type, a projection type, a texture type, and/or a color type. As an option, the command may further include an address identifier for identifying an address to be used while tracking of the matrix, and/or a program identifier for allowing the matrix tracking to be used during various types of graphics-related programmability beyond vertex processing.
In use, vertex data is received after which a state of at least one matrix is tracked. As such, the vertex data may be processed with a current state of the matrix. In one aspect of the present embodiment, the tracking may include assigning an identifier to each of a plurality of states associated with the matrix. As such, the identifier assigned to the current state may be indicated prior to the vertex processing.
As an option, the tracking may be selectively disabled. Further, the vertex data may be conditionally tracked based on whether the tracking is disabled. In one aspect, the state of the matrix may be maintained as a last-tracked state if the tracking is disabled. Further, the matrix may be tracked row-wise utilizing a plurality of registers.